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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server (http://www.etsi.org/ipr ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ECMA on behalf of its members and those of the European 
Telecommunications Standards Institute (ETSI). 



Brief History 



The present document is one of a series of ECMA Standards defining the interworking of services and signalling 
protocols deployed in Corporate telecommunication Networks (CNs). The series uses telecommunication concepts as 
developed by ITU-T and conforms to the framework of International Standards on Open Systems Interconnection as 
defined by ISO/IEC. It has been produced under ETSI work item DTS/ECMA-00194. 

The present document defines the signalling protocol interworking for call diversion supplementary services between a 
Private Integrated Services Network (PISN) and a packet-based private telecommunications network based on the 
Internet Protocol (IP). It is further assumed that the protocol for the PISN part is that defined for the Q reference point 
(QSIG) and that the protocols for the IP-based network are based on ITU-T Recommendation H.323. 

The present document is based upon the practical experience of ECMA member companies and the results of their 
active and continuous participation in the work of ISO/IEC JTCl, ITU-T, ETSI and other international and national 
standardization bodies. It represents a pragmatic and widely based consensus. 

The present document is in complete alignment with International Standard ISO/IEC 2141 1:2001(E) to be published by 
ISO/IEC in 2001. 

Adopted as 2nd Edition of Standard ECMA-309 by the General Assembly of June 2001. 



1 Scope 



The present document specifies signalling interworking between "QSIG" and "H.323" in support of call diversion 
supplementary services within a Corporate telecommunication Network (CN). 

"QSIG" is a signalling protocol that operates at the Q reference point between Private Integrated Services eXchanges 
(PINX) within a Private Integrated Services Network (PISN). The Q reference point is defined in ECMA- 133. A PISN 
provides circuit-switched basic services and supplementary services to its users. QSIG is specified in other Standards, in 
particular ECMA-143 (call control in support of basic services), ECMA-165 (generic functional protocol for the support 
of supplementary services) and a number of standards specifying individual supplementary services. ECMA- 174 
specifies the QSIG protocol in support of call diversion services. 
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"H.323" is a set of signalling protocols for the support of voice or multimedia communication within a packet network, 
in particular a packet network that uses the Internet Protocol (IP) as its network layer protocol (IP network). H.323 
signalling protocols operate between endpoints in an IP network, either indirectly via one or more gatekeepers, or 
directly. An endpoint can be a terminal or a gateway to another network. H.323 is an "umbrella" recommendation 
referring to various ITU-T Recommendations, in particular H.225.0 and H.245 (basic communication capabilities) and 
H.450.1 (generic functional protocol for the support of supplementary services). Recommendation H.450.3 specifies the 
H.323 protocol in support of call diversion services. 

NOTE; ITU-T Recommendation H.450.3 applies only to the 1998 version of H.323 (also known as H.323 
version 2) and to later versions. 

In both ECMA-174 (QSIG) and ITU-Recommendation H.450.3 (H.323), the call diversion supplementary services are 
Call Forwarding Unconditional (SS-CFU), Call Forwarding Busy (SS-CFB), Call Forwarding No Reply (SS-CFNR) 
and Call Deflection (SS-CD). These supplementary services apply during call establishment and provide diversion of an 
incoming call to another destination. 

Interworking between QSIG and H.323 permits a call originating at a user of a PISN to terminate at a user of an IP 
network, or a call originating at a user of an IP network to terminate at a user of a PISN. The present document provides 
the following additional capabilities; 

• a call originating from a PISN and destined for a user of an H.323 network to be diverted by the H.323 network 
to an alternative destination; 

• a call originating from an H.323 network and destined for a user of a PISN to be diverted by the PISN to an 
alternative destination; 

• a call destined for a user of a PISN to be diverted to an alternative destination where that alternative destination 
is in an H.323 network; 

• a call destined for a user of an H.323 network to be diverted to an alternative destination where that alternative 
destination is in a PISN. 

The present document is applicable to any interworking unit that can act as a gateway between a PISN employing QSIG 
and an IP network employing H.323. 



Conformance 



In order to conform to the present document, a gateway shall satisfy the requirements identified in the Implementation 
Conformance Statement (ICS) proforma in annex A. 



Normative references 



The following standards contain provisions which, through references in this text, constitute provisions of this Standard. 
All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the 
possibility of applying the most recent editions of the standards indicated below. 

In the case of references to ECMA Standards that are aligned with ISO/IEC International Standards, the number of the 
appropriate ISO/IEC International Standard is given in brackets after the ECMA reference. 

ECMA- 133; "Private Integrated Services Network (PISN) - Reference Configurations for PISN Exchanges (PINX)" 
(ISO/IEC 11579-1). 

ECMA- 143; "Private Integrated Services Network (PISN) - Circuit Mode Bearer Services - Inter -Exchange Signalling 
Procedures and Protocol (QSIG-BC)" (ISO/IEC 11572). 

ECMA-165; "F*rivate Integrated Services Network (PISN) - Generic Functional Protocol for the Support of 
Supplementary Services - Inter-Exchange Signalling Procedures and Protocol (QSIG-GF)" (ISO/IEC 11582). 

ECMA-174; "F*rivate Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Call Diversion 
Supplementary Services (QSIG-CF)" (ISO/IEC 13873). 



ETSI 



8 ETSI TS 101 906 VI .2.1 (2001-08) 

ECMA-307: "Corporate Telecommunication Networks - Signalling Interworking between QSIG and H.323 - Generic 
Functional Protocol for the Support of Supplementary Services" (ISO/IEC 21409). 

ITU-T Recommendation H.225.0 (1998 or later): "Call signalling protocols and media stream packetization for packet- 
based multimedia communication systems". 

ITU-T Recommendation H.245 (1998 or later): "Control protocol for multimedia communication". 

ITU-T Recommendation H.323 (1998 or later): "Packet-based multimedia communications systems". 

ITU-T Recommendation H.450.1 (1998): "Generic functional protocol for the support of supplementary services 
in H.323". 

ITU-T Recommendaion H.450.3 (1998): "Call diversion supplementary service for H.323". 



4 Definitions 

For the purposes of the present document, the following definitions apply. 

4.1 External definitions 

The present document uses the following terms and definitions apply: 

Call: See ECMA-307. 

Corporate telecommunication Network (CN): See ECMA-307. 

Endpoint: See ITU-T Recommendation H.323. 

Gatekeeper: See ITU-T Recommendation H.323. 

IP network: See ECMA-307. 

Private Integrated Services Network (PISN): See ECMA-307. 

Private Integrated services Network eXchange (PINX): See ECMA-133. 

Additionally the definitions in ECMA-174 and ITU-T Recommendation H.450.3 apply as appropriate. 

4.2 Other definitions 

4.2.1 Association D 

Signalling association between entity D and entity G. 

4.2.2 Association E 

Signalling association between entity E and entity G. 

4.2.3 Association F 

Signalling association between entity F and entity G. 

4.2.4 Association G 

Signalling association between entity G and entity H. 
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4.2.5 Entity A 

Signalling entity at the PINX or H.323 endpoint serving the calling user (user A). 

4.2.6 Entity B 

Signalling entity at the PINX serving the diverting user (user B) or H.323 entity that invokes diversion on behalf of 
user B. 

4.2.7 Entity B' 

Signalling entity at the H.323 endpoint serving user B. 

4.2.8 Entity C 

Signalling entity at the PINX or H.323 endpoint serving the diverted-to-user (user C). 

4.2.9 Entity D 

Signalling entity at the PINX or H.323 endpoint serving an activating user. 

4.2.10 Entity E 

Signalling entity at the PINX or H.323 endpoint serving a deactivating user. 

4.2.11 Entity F 

Signalling entity at the PINX or H.323 endpoint serving an interrogating user. 

4.2.12 Entity G 

Signalling entity for activation / deactivation / interrogation at a PINX or H.323 endpoint serving a diverting endpoint. 

4.2.13 Entity H 

Signalling entity for restriction checking at a PINX or H.323 endpoint serving a diverted-to endpoint. 

4.2.14 Gateway 

A gateway as defined in H.323 specifically for the purpose of interworking with a network employing QSIG. 

4.2.15 Leg A 

Call segment that lies between entity A and the rerouting entity. 

4.2.16 Leg B 

Call segment that lies between the rerouting entity and entity B. 

4.2.17 LegB' 

Call segment that lies between entity B and entity B'. 
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4.2.18 Lege 

Call segment that lies between the rerouting entity and entity C. 

4.2.19 Rerouting entity 

Signalling entity that initiates the rerouting of a call towards user C and clears the call towards user B. 

4.2.20 Scenario A1 

Interworking arrangement in which entity A (PINX A) is in the PISN and the rerouting entity is in the IP network. 

4.2.21 Scenario A2 

Interworking arrangement in which entity A (endpoint A) is in the IP network and the rerouting entity is in the PISN. 

4.2.22 Scenario B1 

Interworking arrangement in which entity B (PINX B) is in the PISN and the rerouting entity is in the IP network. 

4.2.23 Scenario B2 

Interworking arrangement in which entity B (diverting endpoint or its gatekeeper) is in the IP network and the rerouting 
entity is in the PISN. 

4.2.24 Scenario CI 

Interworking arrangement in which entity C (PINX C) is in the PISN and the rerouting entity is in the IP network. 

4.2.25 Scenario C2 

Interworking arrangement in which entity C (endpoint C) is in the IP network and the rerouting entity is in the PISN. 

4.2.26 Scenario D1 

Interworking arrangement in which entity D (PINX D) is in the PISN and entity G (endpoint G) is in the IP network. 

4.2.27 Scenario D2 

Interworking arrangement in which entity D (endpoint D) is in the IP network and entity G (PINX G) is in the PISN. 

4.2.28 Scenario El 

Interworking arrangement in which entity E (PINX E) is in the PISN and entity G (endpoint G) is in the IP network. 

4.2.29 Scenario E2 

Interworking arrangement in which entity E (endpoint E) is in the IP network and entity G (PINX G) is in the PISN. 

4.2.30 Scenario F1 

Interworking arrangement in which entity F (PINX F) is in the PISN and entity G (endpoint G) is in the IP network. 
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4.2.31 Scenario F2 

Interworking arrangement in which entity F (endpoint F) is in the IP network and entity G (PINX G) is in the PISN. 

4.2.32 Scenario G1 

Interworking arrangement in which entity G (PINX G) is in the PISN and entity H (endpoint H) is in the IP network. 

4.2.33 Scenario G2 

Interworking arrangement in which entity G (endpoint G) is in the IP network and entity H (PINX H) is in the PISN. 



Acronyms 



APDU Application Protocol Data Unit 

CN Corporate telecommunication Network 

ICS Implementation Conformance Statement 

IP Internet Protocol 

PINX Private Integrated services Network eXchange 

PISN Private Integrated Services Network 

SS-CD Supplementary Service Call Deflection 

SS-CFB Supplementary Service Call Forwarding Busy 

SS-CFNR Supplementary Service Call Forwarding No Reply 

SS-CFU Supplementary Service Call Forwarding Unconditional 



6 Service architecture 

6.1 Service architecture for invocation and operation 
6.1 .1 ECIVIA-1 74 service arciiitecture 

The QSIG protocol for call diversion invocation and operation is based around four signalling entities or PINX types: 

• entity A - the PINX serving the calling user (user A); 

• entity B - the PINX serving the diverting user (user B); 

• entity C - the PINX serving the diverted-to user (user C); 

• rerouting entity - the PINX that initiates the rerouting of the call towards user C and clears the call towards 
user B. 

Where a user is in another network, the role of entity A, entity B or entity C is performed by the other network, the 
gateway PINX or the two in combination. However, from the QSIG point of view the role is performed by the gateway 
PINX. 

This can be represented diagrammatically as shown in figure 1 . 
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Figure 1 : Call diversion architecture for QSIG 

From this it can be seen that there are three segments or "legs" to the call: 

• leg A from entity A to the rerouting entity; 

• leg B from the rerouting entity to entity B; 

• leg C from the rerouting entity to entity C. 

The QSIG protocol supports each of these three legs. 

The rerouting entity is constrained to be collocated with (in the same PINX as) entity A or entity B (or both if entity A 
and entity B are collocated). In addition, entity C can be collocated with the rerouting entity (and therefore with entity A 
and/or entity B). When an entity is collocated with the rerouting entity, the leg of the call concerned is internal to the 
physical PINX and therefore the QSIG protocol for that leg does not apply. 

6.1 .2 H.450.3 service architecture 

The architecture shown above for QSIG applies also to H.450.3, except that PINXs are replaced by H.323 entities as 
follows; 

• entity A - the calling endpoint; 

• entity B - the entity that invokes diversion on behalf of the diverting user; 

• entity B' - the diverting endpoint; 

• entity C - the diverted-to endpoint; 

• rerouting entity - the entity that initiates the rerouting of the call towards user C and clears the call towards 
user B. 

Where a user is in another network, the role of entity A, entities B and B' or entity C is performed by the other network, 
the gateway, or the two in combination. However, fi^om the H.450.3 point of view the role is performed by the gateway. 

This can be represented diagrammatically as shown in figure 2. 
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Figure 2: Call diversion architecture for H.323 
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From this it can be seen that there are four segments or "legs" to the call: 

• leg A from entity A to the rerouting entity; 

• leg B from the rerouting entity to entity B; 

• leg B' from entity B to entity B'; 

• leg C from the rerouting entity to entity C. 

The H.450.3 protocol supports each of these four legs. 

Entity B is either collocated with entity B' at the diverting endpoint or is located separately in a gatekeeper acting on 
behalf of the diverting endpoint, e.g. for situations where B' is switched off since B' can be a PC. 

The rerouting entity can be collocated with entity A or entity B. Alternatively it can be at a separate device such as a 
gatekeeper or proxy. 



6.1 .3 Scenarios for interworking 



The architectures for QSIG and H.450.3 are very similar. The only difference is the absence of entity B' and leg B' from 
the QSIG architecture. This is not a fundamental difference, but merely reflects the fact that entity B' and leg B' are 
outside the scope of QSIG and therefore no QSIG protocol is required for leg B'. Normally leg B' would correspond to 
the PISN access. 

This means that the H.450.3 architecture is applicable to the inter-networking situation between an IP network and a 
PISN, where one or more of the users involved are served by the IP network and the others are served by the PISN. 

In figure 2 interworking between H.450.3 and QSIG could theoretically occur on any of the four legs. However, 
interworking on leg B' is of less practical use (a network is unlikely to invoke diversion on behalf of a diverting user in 
another network), and also is not possible because there is no support for leg B' in QSIG. Therefore in practice the 
possible points of interworking occur on legs A, B and C. 

For each of the three possible points of interworking, two scenarios arise, depending on which side of the interworking 
point the PISN lies. This gives 6 scenarios in total that need to be considered: 

• Scenario Al: Entity A (PINX A) in PISN, rerouting entity in IP network; 

• Scenario A2: Entity A (endpoint A) in IP network, rerouting entity in PISN; 

• Scenario Bl: Entity B (PINX B) in PISN, rerouting entity in IP network; 

• Scenario B2: Entity B (diverting endpoint or its gatekeeper) in IP network, rerouting entity in PISN; 

• Scenario CI: Entity C (PINX C) in PISN, rerouting entity in IP network; 

• Scenario C2: Entity C (endpoint C) in IP network, rerouting entity in PISN. 

It is possible for more than one scenario to apply to the same call. For example, if entity A and the rerouting entity are 
in a PISN and entities B and C are in the same IP network or different IP networks, interworking according to scenario 
B2 will apply on leg B and interworking according to scenario C2 will apply on leg C. 

A point of interworking will be implemented in a gateway, which acts as both an H.323 endpoint from the point of view 
of the IP network and an end PINX from the point of view of the PISN. 

Multiple scenarios can also occur because of multiple (chained) diversions. 

6.1 .4 Determination of tine location of tine rerouting entity wiien 
interworking 

The particular scenario (or scenarios) that applies depends not only on the location of the users concerned but also on 
the location of the rerouting entity. In each of the scenarios it is possible to locate the rerouting entity within the 
gateway. However, functionally the rerouting entity is separate from the point of interworking and belongs to user B's 
network. When this occurs, interworking occurs on leg A (scenario Al or A2). 
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The possibility of siting the rerouting entity at the gateway arises when the gateway receives a rerouting request (QSIG 
or H.450.3 callRerouting invoke APDU) from entity B. Instead of creating a rerouting entity at the gateway, the 
gateway can choose to pass the rerouting request on into the other network towards entity A. In this case interworking 
occurs on leg B (scenario Bl or B2). 

In either case, interworking can also occur on leg C (scenario CI or C2) if entity C is not in the same type of network as 
the rerouting entity. 

The gateway's decision whether to provide the rerouting entity is an implementation matter. This can, but need not, take 
account of the address of user C. The behaviour of the rerouting entity, if provided at the gateway, is outside the scope 
of the present document and is assumed to be in accordance with the requirements of ECMA-174 (for rerouting requests 
received from the PISN) or in accordance with the requirements of H.450.3 (for rerouting requests received from the IP 
network). 

6.2 Service architecture for activation, deactivation and 
interrogation 

6.2.1 ECMA-1 74 service architecture 

The QSIG protocol for call diversion activation, deactivation and interrogation is based around three signalling entities 
or PINX types: 

• entity D - a PINX serving an activating user; 

• entity E - a PINX serving a deactivating user; 

• entity F - a PINX serving an interrogating user; 

• entity G - a PINX serving a diverting user; 

• entity H - a PINX serving a diverted-to user. 

Where a user is in another network, the role of the entity concerned is performed by the other network, the gateway 
PINX or the two in combination. However, from the QSIG point of view the role is performed by the gateway PINX. 

This can be represented diagrammatically as shown in figure 3. 




Association G 



Entity H 



Figure 3: Call diversion activation / deactivation / interrogation architecture for QSIG 

From this it can be seen that there are four associations between entities: 

• association D between entity D and entity G; 

• association E between entity E and entity G; 

• association F between entity F and entity G; 
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association G between entity G and entity H. 



Associations D, E and F apply to activation, deactivation and interrogation respectively. Association G applies to 
activation and allows entity G to check with entity H whether there are any restrictions that prevent activation of 
diversion. 

The QSIG protocol supports each of these four associations. 

6.2.2 H.450.3 service architecture 

The architecture shown above for QSIG applies also to H.450.3, except that PINXs are replaced by H.323 entities as 
follows: 

• entity D - an activating endpoint; 

• entity E - a deactivating endpoint; 

• entity F - an interrogating endpoint; 

• entity G - a diverting endpoint or gatekeeper; 

• entity H - a diverted-to endpoint. 

Where a user is in another network, the role of the entity concerned is performed by the other network, the gateway, or 
the two in combination. However, fi^om the H.450.3 point of view the role is performed by the gateway. 

As for QSIG, there are four associations: D, E, F and G. 

The H.450.3 protocol supports each of these four associations. 

6.2.3 Scenarios for interworking 

Because the architectures for QSIG and H.450.3 are the same, this architecture is applicable to the inter-networking 
situation between an IP network and a PISN, where one or more of the users involved are served by the IP network and 
the others are served by the PISN. 

In figure 3, interworking between H.450.3 and QSIG can occur on any of the four associations. 

For each of the four possible points of interworking, two scenarios arise, depending on which side of the interworking 
point the PISN lies. This gives 8 scenarios in total that need to be considered: 

• Scenario Dl : Entity D (PINX D) in PISN, entity G (endpoint G) in IP network; 

• Scenario D2: Entity D (endpoint D) in IP network, entity G (PINX G) in PISN; 

• Scenario El: Entity E (PINX E) in PISN, entity G (endpoint G) in IP network; 

• Scenario E2: Entity E (endpoint E) in IP network, entity G (PINX G) in PISN; 

• Scenario Fl: Entity F (PINX F) in PISN, entity G (endpoint G) in IP network; 

• Scenario F2: Entity F (endpoint F) in IP network, entity G (PINX G) in PISN; 

• Scenario Gl : Entity G (PINX G) in PISN, entity H (endpoint H) in IP network; 

• Scenario G2: Entity G (endpoint G) in IP network, entity H (PINX H) in PISN. 

A point of interworking will be implemented in a gateway, which acts as both an H.323 endpoint from the point of view 
of the IP network and an end PINX from the point of view of the PISN. 
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7 



Protocol interworking - General requirements 



Protocol interworking between H.323 and QSIG for call diversion supplementary services shall be in accordance with 
ECMA-307, as modified by the requirements of clause 8. 

When transmitting an APDU in one protocol as a result of receiving the corresponding APDU in the other protocol, the 
mapping of elements in the received APDU to corresponding elements in the transmitted APDU shall be in accordance 
with ECMA-307, where applicable. Optional elements of one protocol that have no corresponding element in the other 
protocol shall be discarded if received. 



8 



Protocol interworking - Messages and APDUs 



In the rules specified below for the different scenarios, the following shall apply: 

1) If the required action is to transmit a QSIG or H.323 FACILITY message but the call state does not permit a 
FACILITY message to be sent at that time, the action to be taken is an implementation matter. 

2) If the required action is to include an APDU in a transmitted QSIG or H.323 message conditional upon that 
message being transmitted and that message is not to be transmitted (owing to basic call interworking 
considerations), the action to be taken is an implementation matter. 

3) If the required action is dependent on the call independent signalling connection extending or being able to be 
extended into the other network and this cannot be achieved, the action to be taken is an implementation matter. 

Annex B shows in diagrammatic form some typical message sequences for some of the scenarios identified in the 
present document. 



8.1 



Scenario A1 



A gateway that supports scenario Al shall behave in accordance with the rules of table 1, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of an H.323 message from a rerouting 
entity, whether this be located in the gateway or in a separate physical entity in the IP network. 

Table 1 : Message and APDU handling requirements for scenario Al 



Rule 


Condition 


Required action 


1 


Receipt of an H.323 FACILITY message containing an 
H.323 clivertingLeglnformationl invoke APDU in tlie 
backward direction, no H.323 CONNECT message 
liaving been received. 


Transmit a OSIG FACILITY message containing a 
OSIG divertingLeglnformationI invoke APDU if tiie 
OSIG call state permits. 


2 


Receipt of an H.323 CONNECT message containing an 
H.323 divertingLeglnformationI invoke APDU. 


If a OSIG CONNECT message is to be 
transmitted, include in the OSIG CONNECT 
message a OSIG divertingLeglnformationI invoke 
APDU. 


3 


Receipt of an H.323 ALERTING message containing an 
H.323 divertingLeglnformation3 invoke APDU. 


If a OSIG ALERTING message is to be 
transmitted, include in the OSIG ALERTING 
message a OSIG divertingLeglnformation3 invoke 
APDU. 


4 


Receipt of an H.323 FACILITY message containing an 
H.323 divertingLeglnformation3 invoke APDU in tlie 
backward direction, no H.323 CONNECT message 
liaving been received. 


Transmit a OSIG FACILITY message containing a 
OSIG divertingLeglnformation3 invoke APDU if the 
OSIG call state permits. 


5 


Receipt of an H.323 CONNECT message containing an 
H.323 divertingLeglnformation3 invoke APDU. 


If a OSIG CONNECT message is to be 
transmitted, include in the OSIG CONNECT 
message a OSIG divertingLeglnformation3 invoke 
APDU. 
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8.2 Scenario A2 

A gateway that supports scenario A2 shall behave in accordance with the rules of table 2, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from a rerouting entity, 
whether this be located in the gateway or in a separate physical entity in the PISN. 

Table 2: Message and APDU handling requirements for scenario A2 



Rule 


Condition 


Required action 


1 


Receipt of a OSIG FACILITY message containing 
a OSIG divertingLeglnformationI invoke APDU in 
the backward direction, no OSIG CONNECT 
message having been received. 


Transmit an H.323 FACILITY message containing an 
H.323 divertingLeglnformationI invoke APDU if the H.323 
call state permits. 


2 


Receipt of a OSIG CONNECT message containing 
a OSIG divertingLeglnformationI invoke APDU. 


If an H.323 CONNECT message is to be transmitted, 
include in the H.323 CONNECT message an H.323 
divertingLeglnformationI invoke APDU. 


3 


Receipt of a OSIG ALERTING message containing 
a OSIG divertingLeglnformation3 invoke APDU. 


If an H.323 ALERTING message is to be transmitted, 
include in the H.323 ALERTING message an H.323 
divertingLeglnformation3 invoke APDU. 


4 


Receipt of a OSIG FACILITY message containing 
a OSIG divertingLeglnformation3 invoke APDU in 
the backward direction, no OSIG CONNECT 
message having been received. 


Transmit an H.323 FACILITY message containing an 
H.323 divertingLeglnformation3 invoke APDU if the H.323 
call state permits. 


5 


Receipt of a OSIG CONNECT message containing 
a OSIG divertingLeglnformation3 invoke APDU. 


If an H.323 CONNECT message is to be transmitted, 
include in the H.323 CONNECT message an H.323 
divertingLeglnformation3 invoke APDU. 


6 


Receipt of a OSIG NOTIFY message containing 
notification "call is diverting" (note 1). This can be 
accompanied by notification "pss1 leNotification" 
with embedded public ISDN Redirection number 
information element. 


Transmit an H.323 FACILITY message containing an 
H.323 divertingLeglnformationI invoke APDU if the H.323 
call state permits (note 2). 


7 


Receipt of a OSIG CONNECT message containing 
no OSIG divertingLeglnformation3 invoke APDU, 
subsequent to transmitting an H.323 FACILITY 
message containing an H.323 
divertingLeglnformationI invoke APDU in 
accordance with rule 6. 


If an H.323 CONNECT message is to be transmitted, 
include in the H.323 CONNECT message an H.323 
divertingLeglnformation3 invoke APDU. 


NOTE 1 : This can arise as a result of tlie PISN routing tlie call on into a public ISDN, where diversion occurs. 
NOTE 2: If no embedded public ISDN Redirection number information element is received, mandatory element 

nominatedNr in the H.323 divertingLeglnformationI invoke APDU shall be coded to indicate that no address is 

available. 



8.3 



Scenario B1 



A gateway that supports scenario Bl shall behave in accordance with the rules of table 3, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of an H.323 message from a rerouting 
entity, whether this be located in the gateway or in a separate physical entity in the IP network, or the receipt of a QSIG 
message from entity B. 
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Table 3: Message and APDU handling requirements for scenario B1 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG FACILITY message containing a 
QSIG callRerouting invoke APDU in tlie backward 
direction, no QSIG CONNECT message liaving 
been received. 


Transmit an H.323 FACILITY message containing an 
H.323 callRerouting invoke APDU if the H.323 call state 
permits. 


2 


Receipt of an H.323 FACILITY message containing 
an H.323 callRerouting return result APDU in 
response to an H.323 callRerouting invoke APDU. 


Transmit a OSIG FACILITY message containing a 
OSIG callRerouting return result APDU if the OSIG call 
state permits. 


3 


Receipt of an H.323 RELEASE COMPLETE 
message containing an H.323 callRerouting return 
result APDU in response to an H.323 callRerouting 
invoke APDU. 


Transmit a OSIG DISCONNECT message containing a 
OSIG callRerouting return result APDU if the OSIG call 
state permits. 


4 


Receipt of an H.323 FACILITY message containing 
an H.323 callRerouting return error APDU in 
response to an H.323 callRerouting invoke APDU. 


Transmit a OSIG FACILITY message containing a 
OSIG callRerouting return error APDU if the OSIG call 
state permits. 


5 


Receipt of an H.323 RELEASE COMPLETE 
message containing an H.323 callRerouting return 
error APDU in response to an H.323 callRerouting 
invoke APDU. 


Transmit a OSIG DISCONNECT message containing a 
OSIG callRerouting return error APDU if the OSIG call 
state permits. 


6 


Receipt of an H.323 FACILITY message containing 
an H.323 cfnrDivertedLegFailed invoke APDU in the 
forward direction 


Transmit a OSIG FACILITY message containing a 
OSIG CfnrDivertedLegFailed invoke APDU if the OSIG 
call state permits. 



8.4 



Scenario B2 



A gateway that supports scenario B2 shall behave in accordance with the rules of table 4, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from a rerouting entity, 
whether this be located in the gateway or in a separate physical entity in the PISN, or receipt of an H.323 message from 
entity B. 

Table 4: Message and APDU handling requirements for scenario B2 



Rule 


Condition 


Required action 


1 


Receipt of an H.323 FACILITY message containing 
an H.323 callRerouting invoke APDU in the 
backward direction, no H.323 CONNECT message 
having been received. 


Transmit a OSIG FACILITY message containing a 
OSIG callRerouting invoke APDU if the OSIG call 
state permits. 


2 


Receipt of a OSIG FACILITY message containing a 
OSIG callRerouting return result APDU in response 
to a OSIG callRerouting invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 callRerouting return result APDU if the H.323 
call state permits. 


3 


Receipt of a OSIG DISCONNECT message 
containing a OSIG callRerouting return result APDU 
in response to a OSIG callRerouting invoke APDU. 


Transmit an H.323 RELEASE COMPLETE message 
containing an H.323 callRerouting return result APDU 
if the H.323 call state permits. 


4 


Receipt of a OSIG FACILITY message containing a 
OSIG callRerouting return error APDU in response 
to a OSIG callRerouting invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 callRerouting return error APDU if the H.323 
call state permits. 


4 


Receipt of a OSIG DISCONNECT message 
containing a OSIG callRerouting return error APDU 
in response to a OSIG callRerouting invoke APDU. 


Transmit an H.323 RELEASE COMPLETE message 
containing an H.323 callRerouting return error APDU 
if the H.323 call state permits. 


6 


Receipt of a OSIG FACILITY message containing a 
OSIG CfnrDivertedLegFailed invoke APDU in the 
forward direction. 


Transmit an H.323 FACILITY message containing an 
H.323 CfnrDivertedLegFailed invoke APDU if the 
H.323 call state permits. 



8.5 



Scenario C1 



A gateway that supports scenario CI shall behave in accordance with the rules of table 5, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of an H.323 message from a rerouting 
entity, whether this be located in the gateway or in a separate physical entity in the IP network, or receipt of a QSIG 
message from entity C. 
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Table 5: Message and APDU handling requirements for scenario CI 



Rule 


Condition 


Required action 


1 


Receipt of an H.323 SETUP message containing 
an H.323 divertingLeglnformation2 invoke APDU. 


If a QSIG SETUP message is to be transmitted, include 
in the QSIG SETUP message a QSIG 
divertingLeglnformation2 invoke APDU. 


2 


Receipt of a QSIG ALERTING message 
containing a QSIG divertingLeglnformation3 
invoke APDU. 


If an H.323 ALERTING message is to be transmitted, 
include in the H.323 ALERTING message an H.323 
divertingLeglnformation3 invoke APDU. 


3 


Receipt of a QSIG FACILITY message containing 
a QSIG divertingLeglnformation3 invoke APDU in 
the backward direction, no QSIG GQNNECT 
message having been received. 


Transmit an H.323 FACILITY message containing an 
H.323 divertingLeglnformation3 invoke APDU if the 
H.323 call state permits. 


4 


Receipt of a QSIG GQNNECT message 
containing a QSIG divertingLeglnformation3 
invoke APDU. 


If an H.323 CQNNECT message is to be transmitted, 
include in the H.323 CQNNECT message an H.323 
divertingLeglnformation3 invoke APDU. 



8.6 



Scenario C2 



A gateway that supports scenario C2 shall behave in accordance with the rules of table 6, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from a rerouting entity, 
whether this be located in the gateway or in a separate physical entity in the PISN, or the receipt of an H.323 message 
from entity C. 

Table 6: Message and APDU handling requirements for scenario C2 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG SETUP message containing a 
QSIG divertingLeglnformation2 invoke APDU. 


If an H.323 SETUP message is to be transmitted, 
include in the H.323 SETUP message an H.323 
divertingLeglnformation2 invoke APDU. 


2 


Receipt of an H.323 ALERTING message containing 
an H.323 divertingLeglnformation3 invoke APDU. 


If a QSIG ALERTING message is to be transmitted, 
include in the QSIG ALERTING message a QSIG 
divertingLeglnformation3 invoke APDU. 


3 


Receipt of an H.323 FACILITY message containing 
an H.323 divertingLeglnformation3 invoke APDU in 
the backward direction, no QSIG CQNNECT 
message having been received. 


Transmit a QSIG FACILITY message containing a QSIG 
divertingLeglnformation3 invoke APDU if the QSIG call 
state permits. 


4 


Receipt of an H.323 CQNNECT message containing 
an H.323 divertingLeglnformation3 invoke APDU. 


If a QSIG CQNNECT message is to be transmitted, 
include in the QSIG CQNNECT message a QSIG 
divertingLeglnformation3 invoke APDU. 



8.7 Scenario D1 

A gateway that supports scenario Dl shall behave in accordance with the rules of table 7, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity D or an 
H.323 message from entity G. 

Table 7: Message and APDU handling requirements for scenario Dl 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG activateDiversionQ invoke APDU 
carried on a call independent signalling connection. 


If the call independent signalling connection extends 
or is able to be extended into the IP network, transmit 
an H.323 activateDiversionQ invoke APDU. 


2 


Receipt of an H.323 activateDiversionQ return result 
APDU carried on a call independent signalling 
connection in response to an H.323 
activateDiversionQ invoke APDU. 


Transmit a QSIG activateDiversionQ return result 
APDU. 


3 


Receipt of an H.323 activateDiversionQ return error 
APDU carried on a call independent signalling 
connection in response to an H.323 
activateDiversionQ invoke APDU. 


Transmit a QSIG activateDiversionQ return error 
APDU. 
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8.8 



Scenario D2 



A gateway that supports scenario D2 shall behave in accordance with the rules of table 8, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of an H.323 message from entity D or a 
QSIG message from entity G. 

Table 8: Message and APDU handling requirements for scenario D2 



Rule 


Condition 


Required action 


1 


Receipt of an H.323 activateDiversionQ invoke APDU 
carried on a call independent signalling connection. 


If the call independent signalling connection extends 
or is able to be extended into the PISN, transmit a 
QSIG activateDiversionQ invoke APDU. 


2 


Receipt of a QSIG activateDiversionQ return result 
APDU carried on a call independent signalling 
connection in response to a QSIG activateDiversionQ 
invoke APDU. 


Transmit an H.323 activateDiversionQ return result 
APDU. 


3 


Receipt of a QSIG activateDiversionQ return error APDU 
carried on a call independent signalling connection in 
response to a QSIG activateDiversionQ invoke APDU. 


Transmit an H.323 activateDiversionQ return error 
APDU. 



8.9 



Scenario E1 



A gateway that supports scenario El shall behave in accordance with the rules of table 9, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity E or an 
H.323 message from entity G. 

Table 9: Message and APDU handling requirements for scenario E1 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG deactivateDiversionQ invoke APDU 
carried on a call independent signalling connection. 


If the call independent signalling connection 
extends or is able to be extended into the IP 
network, transmit an H.323 deactivateDiversionQ 
invoke APDU. 


2 


Receipt of an H.323 deactivateDiversionQ return result 
APDU carried on a call independent signalling 
connection in response to an H.323 
deactivateDiversionQ invoke APDU. 


Transmit a QSIG deactivateDiversionQ return result 
APDU. 


3 


Receipt of an H.323 deactivateDiversionQ return error 
APDU carried on a call independent signalling 
connection in response to an H.323 
deactivateDiversionQ invoke APDU. 


Transmit a QSIG deactivateDiversionQ return error 
APDU. 



8.10 Scenario E2 

A gateway that supports scenario E2 shall behave in accordance with the rules of table 10, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of an H.323 message from entity E or a 
QSIG message from entity G. 
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Table 10: Message and APDU handling requirements for scenario E2 



Rule 


Condition 


Required action 


1 


Receipt of an H.323 deactivateDiversionQ invoke 
APDU carried on a call independent signalling 
connection 


If the call independent signalling connection extends 
or is able to be extended into the PISN, transmit a 
QSIG deactivateDiversionQ invoke APDU. 


2 


Receipt of a QSIG deactivateDiversionQ return 
result APDU carried on a call independent signalling 
connection in response to a QSIG 
deactivateDiversionQ invoke APDU. 


Transmit an H.323 deactivateDiversionQ return result 
APDU. 


3 


Receipt of a QSIG deactivateDiversionQ return 
error APDU carried on a call independent signalling 
connection in response to a QSIG 
deactivateDiversionQ invoke APDU. 


Transmit an H.323 deactivateDiversionQ return error 
APDU. 



8.11 Scenario F1 

A gateway that supports scenario Fl shall behave in accordance with the rules of table 1 1, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity F or an 
H.323 message from entity G. 

Table 11 : Message and APDU handling requirements for scenario Fl 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG InterrogateDiversionQ invoke 
APDU carried on a call independent signalling 
connection. 


If the call independent signalling connection extends or 
is able to be extended into the IP network, transmit an 
H.323 InterrogateDiversionQ invoke APDU. 


2 


Receipt of an H.323 InterrogateDiversionQ return 
result APDU carried on a call independent signalling 
connection in response to an H.323 
InterrogateDiversionQ invoke APDU. 


Transmit a QSIG InterrogateDiversionQ return result 
APDU. 


3 


Receipt of an H.323 InterrogateDiversionQ return 
error APDU carried on a call independent signalling 
connection in response to an H.323 
InterrogateDiversionQ invoke APDU. 


Transmit a QSIG InterrogateDiversionQ return error 
APDU. 



8.12 Scenario F2 

A gateway that supports scenario F2 shall behave in accordance with the rules of table 12, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of an H.323 message from entity F or a 
QSIG message from entity G. 

Table 12: Message and APDU handling requirements for scenario F2 



Rule 


Condition 


Required action 


1 


Receipt of an H.323 InterrogateDiversionQ invoke APDU 
carried on a call independent signalling connection. 


If the call independent signalling connection 
extends or is able to be extended into the PISN, 
transmit a QSIG InterrogateDiversionQ invoke 
APDU. 


2 


Receipt of a QSIG InterrogateDiversionQ return result 
APDU carried on a call independent signalling 
connection in response to a QSIG InterrogateDiversionQ 
invoke APDU. 


Transmit an H.323 InterrogateDiversionQ return 
result APDU. 


3 


Receipt of a QSIG InterrogateDiversionQ return error 
APDU carried on a call independent signalling 
connection in response to a QSIG InterrogateDiversionQ 
invoke APDU. 


Transmit an H.323 InterrogateDiversionQ return 
error APDU. 
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8.13 Scenario G1 

A gateway that supports scenario Gl shall behave in accordance with the rules of table 13, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity G or an 
H.323 message from entity H. 

Table 13: Message and APDU handling requirements for scenario G1 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG checkRestriction invoke APDU 
carried on a call independent signalling connection. 


If the call independent signalling connection extends 
or is able to be extended into the IP network, 
transmit an H.323 checkRestriction invoke APDU. 


2 


Receipt of an H.323 checkRestriction return result 
APDU carried on a call independent signalling 
connection in response to an H.323 checkRestriction 
invoke APDU. 


Transmit a QSIG checkRestriction return result 
APDU. 


3 


Receipt of an H.323 checkRestriction return error 
APDU carried on a call independent signalling 
connection in response to an H.323 checkRestriction 
invoke APDU. 


Transmit a QSIG checkRestriction return error 
APDU. 



8.14 Scenario G2 

A gateway that supports scenario G2 shall behave in accordance with the rules of table 14, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of an H.323 message from entity G or a 
QSIG message from entity H. 

Table 14: Message and APDU handling requirements for scenario G2 



Rule 


Condition 


Required action 


1 


Receipt of an H.323 checkRestriction invoke 
APDU carried on a call independent signalling 
connection. 


If the call independent signalling connection extends or 
is able to be extended into the PISN, transmit a QSIG 
checkRestriction invoke APDU. 


2 


Receipt of a QSIG checkRestriction return result 
APDU carried on a call independent signalling 
connection in response to a QSIG 
checkRestriction invoke APDU. 


Transmit an H.323 checkRestriction return result APDU. 


3 


Receipt of a QSIG checkRestriction return error 
APDU carried on a call independent signalling 
connection in response to a QSIG 
checkRestriction invoke APDU. 


Transmit an H.323 checkRestriction return error APDU. 
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Annex A (normative): 

Implementation Conformance Statement (ICS) proforma 



Notwithstanding the provisions of the copyright clause related to the text of the present document, ETSI grants that 
users of the present document may freely reproduce the ICS proforma in this annex so that it can be used for its 
intended purposes and may further publish the completed ICS. 



A.1 Introduction 

A.1 .1 Purpose of an ICS proforma 

The supplier of an implementation which is claimed to conform to the present document shall complete the following 
Implementation Conformance Statement (ICS) proforma. 

A completed ICS proforma is the ICS for the implementation in question. The ICS is a statement of which capabilities 
and options have been implemented for a given specification. 

The ICS can have a number of uses, including use: 

- by the implementor, as a check list for implementations to reduce the risk of unintended non-conformance, e.g. 
through oversight; 

- by the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication of the 
capabilities of the implementation, stated relative to the common basis for understanding provided by the 
Standard's ICS proforma; 

- by the user or potential user of the implementation, as a basis for initially checking the possibility of 
interworking with another implementation - while interworking can never be guaranteed, failure to interwork can 
often be predicted from incompatible ICS; 

- by a tester, as the basis for selecting appropriate tests against which to assess the claim for conformance of the 
implementation. 



A.2 Instructions for completing the ICS proforma 
A.2.1 General structure of the ICS proforma 

The ICS proforma is a fixed format questionnaire divided into sub-clauses each containing a group of individual items. 
Each item is identified by an item reference, the description of the item (question to be answered), and the reference(s) 
to the clause(s) that specifies (specify) the item in the main body of the present document. 

The "Conditions for Status" column contains a specification, if appropriate, of the predicate upon which a conditional 
status is based. The indication of an item reference in this column indicates a simple-predicate condition (support of this 
item is dependent on the support marked for the referenced item). 

The "Status" column indicates whether an item is applicable and if so whether support is mandatory or optional. The 
following terms are used: 

I irrelevant or out-of-scope - this capability is outside the scope of the standard to which this ICS 

proforma applies and is not subject to conformance testing in this context; 

M mandatory (the capability is required for conformance to the standard); 

N/A not applicable - in the given context, it is impossible to use the capability; no answer in the support 

column is required; 
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O optional (the capability is not required for conformance to the standard, but if the capability is 

implemented it is required to conform to the specification in the present document); 

0.<n> qualified optional - in this case, <n> is an integer that identifies a unique group of related optional 

items; if no additional qualification is indicated, the support of at least one of the optional items is 
required for conformance to the present document; otherwise, the qualification and logic of the 
selection among the optional items is defined below the table explicitly; 

X excluded or prohibited - there is a requirement not to use this capability in a given context. 

Answers to the questionnaire items are to be provided in the "Support" column, by simply marking an answer to 
indicate a restricted choice (Yes, No or N/A). In specific cases, the indication of explicit values may be requested. 
Where a support column box is left blank, no answer is required. 

If a "prerequisite line" (see clause A.2.4) is used after a clause heading or table title, and its predicate is false, no answer 
is required for the whole clause or table, respectively. 

A.2.2 Additional Information 

Items of Additional Information allow a supplier to provide further information intended to assist the interpretation of 
the ICS. It is not intended or expected that a large quantity will be supplied, and an ICS can be considered complete 
without any such information. Examples might be an outline of the ways in which a (single) implementation can be set 
up to operate in a variety of environments and configurations. 

References to items of Additional Information may be entered next to any answer in the questionnaire, and may be 
included in items of Exception Information. 



A.2.3 Exception Information 



It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status (after any 
conditions have been applied) in a way that conflicts with the indicated requirement. No pre-printed answer will be 
found in the Support column for this. Instead, the supplier is required to write into the support column an x.<i> 
reference to an item of Exception Information, and to provide the appropriate rationale in the Exception item itself. 

An implementation for which an Exception item is required in this way does not conform to the present document. A 
possible reason for the situation described above is that a defect in the standard has been reported, a correction for 
which is expected to change the requirement not met by the implementation. 

A.2.4 Further indications of the ICS proforma tables 

In addition to the columns of a table, the following information may be indicated: 

"Prerequisite line" 

A prerequisite line after a clause heading or table title indicates that the whole clause or the whole table is not required 
to be completed if the predicate is false. 

"Qualification" 

At the end of a table, a detailed qualification for a group of optional items may be indicated, as specified in the 
description of the status "qualified optional" in clause in A.2.1. 

"Comments" 

This box at the end of a table allows a supplier to enter any comments to that table. Comments may also be provided 
separately (without using this box). 
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A.3 
A.3.1 



Identification of the Implementation 
Implementation Identification 



Supplier (note 1) 




Contact point for queries about tlie ICS (note 1) 




Implementation Name(s) and Version(s) (note 1, 
note 2) 




Other information necessary for full identification - 
e.g., name(s) and version(s) for machines and/or 
operating systems; System name(s) 




NOTE 1 : Only the first three items are required for all implementations; other information 

may be completed as appropriate in meeting the requirement for full identification. 

NOTE 2: The terms Name and Version should be interpreted appropriately to correspond 
with a suppliers terminology (e.g. Type, Series, Model). 



A.3. 2 Specification for which this ICS applies 



Title 


Corporate Telecommunication Networks (CN); Signalling 
interworking between OSIG and H.323; Call Diversion 
supplementary services. 


Version 


1.2.1 


Corrigenda Implemented (if applicable) 




Addenda Implemented (if applicable) 




Amendments Implemented (if applicable) 




Have any exception items been required ? 


No[ ]Yes[ ] 

(The answer Yes means that the implementation does not 

conform to the present document) (Note) 


Date of Statement 




NOTE: In this case, an explanation shall be given of the nature of non-conformance either below or on a 
separate sheet of paper. 
Nature of non-conformance (if applicable): 
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A.4 Major capabilities 



Table A.1 : Major capabilities 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MC1 


support rerouting entity functionality for 
liandling rerouting requests received from 
tlie PISN 







6.1.4 


[ ]Yes [ ]No 


MC2 


support rerouting entity functionality for 
handling rerouting requests received from 
the IP network 







6.1.4 


[ ]Yes [ ]No 


MC3 


support scenario A1 




M 


6.1.3 


[]Yes 


MC4 


support scenario A2 




M 


6.1.3 


[]Yes 


MC5 


support scenario B1 


MC1 
NOT MC1 




M 


6.1.3 


[ ]Yes [ ]No 
[]Yes 


MC6 


support scenario B2 


MC2 
NOT MC2 




M 


6.1.3 


[ ]Yes [ ]No 
[]Yes 


MC7 


support scenario C1 




M 


6.1.3 


[]Yes 


MC8 


support scenario C2 




M 


6.1.3 


[]Yes 


MC9 


support scenarios D1 and D2 (remote 
activation) 







6.2.3 


[ ]Yes [ ]No 


MC10 


support scenarios E1 and E2 (remote 
deactivation) 




o 


6.2.3 


[ ]Yes [ ]No 


MC11 


support scenarios F1 and F2 (remote 
interrogation) 







6.2.3 


[ ]Yes [ ]No 


MC12 


support scenarios G1 and G2 (remote 
restriction checking for activation) 







6.2.3 


[ ]Yes [ ]No 


Comments: 





A. 5 General requirements 

Table A.2: General requirements for protocol interworking 



Item 


Question: 
Does tlie implementation... 


Conditions for 
status 


Status 


Reference 


Support 


GR1 


perform protocol interworking in accordance 
with ECMA-307 




M 


7 


[]Yes 


Comments: 



ETSI 



27 



ETSI TS 101 906 VI .2.1 (2001-08) 



A.6 Message and APDU handling 

A.6.1 Message and APDU handling for scenario A1 

Table A.3: Message and APDU handling for scenario A1 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MAI 1 


behave in accordance with rule 1 for 
scenario Al 




M 


8.1 


[]Yes 


MAI 2 


behave in accordance with rule 2 for 
scenario Al 




M 


8.1 


[]Yes 


MAI 3 


behave in accordance with rule 3 for 
scenario Al 




M 


8.1 


[]Yes 


MAI 4 


behave in accordance with rule 4 for 
scenario Al 




M 


8.1 


[]Yes 


MAI 5 


behave in accordance with rule 5 for 
scenario Al 




M 


8.1 


[]Yes 


Comments: 



A.6. 2 Message and APDU handling for scenario A2 

Table A.4: IVIessage and APDU handling for scenario A2 



Item 


Question: 
Does tlie implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MA2 1 


behave in accordance with rule 1 for 
scenario A2 




M 


8.2 


[]Yes 


MA2 2 


behave in accordance with rule 2 for 
scenario A2 




M 


8.2 


[]Yes 


MA2 3 


behave in accordance with rule 3 for 
scenario A2 




M 


8.2 


[]Yes 


MA2 4 


behave in accordance with rule 4 for 
scenario A2 




M 


8.2 


[]Yes 


MA2 5 


behave in accordance with rule 5 for 
scenario A2 




M 


8.2 


[]Yes 


MA2 6 


behave in accordance with rule 6 for 
scenario A2 




M 


8.2 


[]Yes 


MA2 7 


behave in accordance with rule 7 for 
scenario A2 




M 


8.2 


[]Yes 


MA2 8 


behave in accordance with rule 8 for 
scenario A2 




M 


8.2 


[]Yes 


Comments: 
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A.6.3 Message and APDU handling for scenario B1 

Table A.5: Message and APDU handling for scenario B1 



Item 


Question: 
Does the Implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MB1 1 


behave in accordance with rule 1 for 
scenario B1 


MC5 


M 


8.3 


[]Yes 


MB1 2 


behave in accordance with rule 2 for 
scenario B1 


MC5 


M 


8.3 


[]Yes 


MB1 3 


behave in accordance with rule 3 for 
scenario B1 


MC5 


M 


8.3 


[]Yes 


MB1 4 


behave in accordance with rule 4 for 
scenario B1 


MC5 


M 


8.3 


[]Yes 


Comments: 



A.6.4 IVIessage and APDU handling for scenario B2 

Table A.6: Message and APDU handling for scenario B2 



Item 


Question: 
Does the Implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MB2 1 


behave in accordance with rule 1 for 
scenario B2 


MC6 


M 


8.4 


[]Yes 


MB2 2 


behave in accordance with rule 2 for 
scenario B2 


MC6 


M 


8.4 


[]Yes 


MB2 3 


behave in accordance with rule 3 for 
scenario B2 


MC6 


M 


8.4 


[]Yes 


MB2 4 


behave in accordance with rule 4 for 
scenario B2 


MC6 


M 


8.4 


[]Yes 


Comments: 



A.6. 5 IVIessage and APDU handling for scenario C1 

Table A.7: Message and APDU handling for scenario C1 



Item 


Question: 
Does the Implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MCI 1 


behave in accordance with rule 1 for 
scenario C1 




M 


8.5 


[]Yes 


MC1 2 


behave in accordance with rule 2 for 
scenario C1 




M 


8.5 


[]Yes 


MC1 3 


behave in accordance with rule 3 for 
scenario C1 




M 


8.5 


[]Yes 


MC1 4 


behave in accordance with rule 4 for 
scenario C1 




M 


8.5 


[]Yes 


Comments: 
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A.6.6 Message and APDU handling for scenario C2 

Table A.8: Message and APDU handling for scenario C2 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MC2 1 


behave in accordance with rule 1 for 
scenario C2 




M 


8.6 


[]Yes 


MC2 2 


behave in accordance with rule 2 for 
scenario C2 




M 


8.6 


[]Yes 


MC2 3 


behave in accordance with rule 3 for 
scenario C2 




M 


8.6 


[]Yes 


MC2 4 


behave in accordance with rule 4 for 
scenario C2 




M 


8.6 


[]Yes 


Comments: 



A.6.7 IVIessage and APDU handling for scenario D1 

Table A.9: Message and APDU handling for scenario D1 



Item 


Question: 
Does tlie implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MD1 1 


behave in accordance with rule 1 for 
scenario D1 


MC9 


M 


8.7 


[]Yes 


MD1 2 


behave in accordance with rule 2 for 
scenario D1 


MC9 


M 


8.7 


[]Yes 


MD1 3 


behave in accordance with rule 3 for 
scenario D1 


MC9 


M 


8.7 


[]Yes 


Comments: 



A.6.8 IVIessage and APDU handling for scenario D2 

Table A.10: Message and APDU handling for scenario D2 



Item 


Question: 
Does the Implementation... 


Conditions 
for status 


Status 


Reference 


Support 


MD2 1 


behave in accordance with rule 1 for 
scenario D2 


MC9 


M 


8.8 


[]Yes 


MD2 2 


behave in accordance with rule 2 for 
scenario D2 


MC9 


M 


8.8 


[]Yes 


MD2 3 


behave in accordance with rule 3 for 
scenario D2 


MC9 


M 


8.8 


[]Yes 


Comments: 
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A.6.9 Message and APDU handling for scenario E1 

Table A.11 : Message and APDU handling for scenario E1 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


ME1 1 


behave in accordance with rule 1 for 
scenario E1 


MC10 


M 


8.9 


[]Yes 


ME1 2 


behave in accordance with rule 2 for 
scenario E1 


MC10 


M 


8.9 


[]Yes 


ME1 3 


behave in accordance with rule 3 for 
scenario E1 


MC10 


M 


8.9 


[]Yes 


Comments: 



A.6.10 IVIessage and APDU handling for scenario E2 

Table A.12: IVIessage and APDU handling for scenario E2 



Item 


Question: 
Does tlie implementation... 


Conditions for 
status 


Status 


Reference 


Support 


ME2 1 


behave in accordance with rule 1 for 
scenario E2 


MC10 


M 


8.10 


[]Yes 


ME2 2 


behave in accordance with rule 2 for 
scenario E2 


MC10 


M 


8.10 


[]Yes 


ME2 3 


behave in accordance with rule 3 for 
scenario E2 


MC10 


M 


8.10 


[]Yes 


Comments: 



A.6.1 1 IVIessage and APDU handling for scenario F1 

Table A.13: IVIessage and APDU handling for scenario F1 



Item 


Question: 
Does tlie implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MF1 1 


behave in accordance with rule 1 for 
scenario F1 


MC11 


M 


8.11 


[]Yes 


MF1 2 


behave in accordance with rule 2 for 
scenario F1 


MC11 


M 


8.11 


[]Yes 


MF1 3 


behave in accordance with rule 3 for 
scenario F1 


MC11 


M 


8.11 


[]Yes 


Comments: 
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A.6.12 Message and APDU handling for scenario F2 

Table A.I 4: Message and APDU handling for scenario F2 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MF2 1 


behave in accordance with rule 1 for 
scenario F2 


MC11 


M 


8.12 


[]Yes 


MF2 2 


behave in accordance with rule 2 for 
scenario F2 


MC11 


M 


8.12 


[]Yes 


MF2 3 


behave in accordance with rule 3 for 
scenario F2 


MC11 


M 


8.12 


[]Yes 


Comments: 



A.6.13 IVIessage and APDU handling for scenario G1 

Table A.I 5: Message and APDU handling for scenario G1 



Item 


Question: 
Does tlie implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MG1 1 


behave in accordance with rule 1 for 
scenario 01 


MCI 2 


M 


8.13 


[]Yes 


MG1 2 


behave in accordance with rule 2 for 
scenario G1 


MCI 2 


M 


8.13 


[]Yes 


MG1 3 


behave in accordance with rule 3 for 
scenario G1 


MCI 2 


M 


8.13 


[]Yes 


Comments: 



A.6.14 IVIessage and APDU handling for scenario G2 

Table A.I 6: Message and APDU handling for scenario G2 



Item 


Question: 
Does tlie implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MG2 1 


behave in accordance with rule 1 for 
scenario G2 


MCI 2 


M 


8.14 


[]Yes 


MG2 2 


behave in accordance with rule 2 for 
scenario G2 


MCI 2 


M 


8.14 


[]Yes 


MG2 3 


behave in accordance with rule 3 for 
scenario G2 


MCI 2 


M 


8.14 


[]Yes 


Comments: 
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Annex B (informative): 

Example message sequence diagrams 

This annex contains some examples of typical message sequences for some of the scenarios identified in the present 
document. Although the examples shown are typical, other valid message sequences are possible. 

In the figures, the arrows indicate the direction of messages. For each message, only the message name and the 
contained APDU (if applicable) are shown. Other message contents are not shown, in particular for unsuccessful 
attempts at call diversion. The following abbreviations are used: 

.inv invoke APDU 

.res return result APDU 



B.1 Scenario A1 



PISN 



Interworking unit 



QSIG SETUP 



QSIG CALL PROCEEDING 



QSIG FACILITY 
divertingLeglnformationl.inv 



QSIG ALERTING 



QSIG CONNECT 
divertingLeglnformationS.inv 



IP network 



H.225.0 SETUP 



H.225.0 CALL PROCEEDING 



H.225.0 FACILITY 
divertingLeglnformationl.inv 



H.225.0 ALERTING 



H.225.0 CONNECT 
divertingLeglnformationS.inv 



Figure B.1 : Example of scenario A1 (caii forwarding unconditionai or call forwarding busy) 



ETSI 



33 



ETSI TS 101 906 VI .2.1 (2001-08) 



B.2 Scenario A2 



IP network 


Interworking unit 


PISN 




k. 








H.225.0 SETUP 


^ 


M 


OSIG SETUP 


H.225.0 CALL PROCEEDING 


^ 




OSIG CALL PROCEEDING 


^ 


OSIG ALERTING 


H.225.0 ALERTING 


^ 


^ 


OSIG FACILITY 


H.225.0 FACILIPr' 
divertingLeglnformationl.inv 


di\«rtingLeglnformation1.inv 


^ 


OSIG CONNECT 


H.225.0 CONNECT 
divertingLeglnformationS.inv 


divertingLeglnformationS.inv 



Figure B.2: Example of scenario A2 (caii forwarding no repiy) 



ETSI 



34 



ETSI TS 101 906 VI .2.1 (2001-08) 



B.3 Scenario B1 



IP netowork 



Interworking unit 



H. 225.0 SETUP 



H.225.0 CALL PROCEEDING 



H.225.0 ALERTING 



H.225.0 FACILITY 
callRerouting.inv 



H.225.0 FACILITY 
callRerouting.res 



H.225.0 DISCONNECT 



H.225.0 RELEASE 



H.225.0 RELEASE COMPLETE 



PISN 



OSIG SETUP 



OSIG CALL PROCEEDING 



OSIG ALERTING 



OSIG.O FACILITY 
callRerouteing.inv 



OSIG.O FACILITY 
callRerouteing.res 



OSIG.O RELEASE COMPLETE 



Figure B.3: Example of scenario B1 (caii forwarding no repiy) 
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B.4 Scenario B2 



PISN 



Interworking unit 



QSIG SETUP 



QSIG CALL PROCEEDING 



QSIG FACILITY 

callRerouting.inv 



QSIG FACILITY 
callRerouting.res 



QSIG DISCQNNECT 



QSIG RELEASE 



QSIG RELEASE CQMPLETE 



IP network 



H.225.0 SETUP 



H.225.0 CALL PRQCEEDING 



H.225.0 FACILITY 
callRerouteing.inv 



H.225.0 FACILITY 
callRerouteing.res 



H.225.0 RELEASE CQMPLETE 



Figure B.4: Example of scenario B2 (call forwarding unconditional or call forwarding busy) 



B.5 Scenario C1 



IP network 



Interworking unit 



H.225.0 SETUP 
divertingLeglnformationl.inv 



H.225.0 CALL PROCEEDING 



H.225.0 ALERTING 



H.225.0 CONNECT 
divertingLeglnformationS.inv 



PISN 



OSIG SETUP 
divertingLeglnformationl.inv 



OSIG CALL PROCEEDING 



OSIG ALERTING 



OSIG CONNECT 
divertingLeglnformationS.inv 



Figure B.5: Example of scenario C1 
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B.6 Scenario C2 



PISN 



Interworking unit 



QSIG SETUP 
divertingLeglnformationl.inv 



QSIG CALL PROCEEDING 



QSIG ALERTING 



QSIG CONNECT 
divertingLeglnformationS.inv 



IP network 



H.225.0 SETUP 
divertingLeglnformationl.inv 



H.225.0 CALL PROCEEDING 



H.225.0 ALERTING 



H.225.0 CONNECT 
divertingLeglnformationS.inv 



Figure B.6: Example of scenario C2 
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